1. Field of the Invention
The present invention relates to a data structure used to represent a source file written in the Object Management Group's Interface Definition Language. In particular, the data structure is a representation of an IDL translation unit and can be stored in a file or database for use as an intermediate format between IDL compilers and code generators.
2. Background
Distributed object computing combines the concepts of distributed computing and object-oriented computing. Distributed computing consists of two or more pieces of software sharing information with each other. These two pieces of software could be running on the same computer or on different computers connected to a common network. Most distributed computing is based on a client/server mode. With the client/server model, two major types of software are utilized: client software, which requests the information or service, and server software, which provides the information or service.
Object-oriented computing is based upon the object model where pieces of code called "objects"--often abstracted from real objects in the real world--own data (called "attributes" in object-oriented programming parlance) and provide services through methods (also known as "operations" or "member functions"). The data and methods contained in an object may be "public" or "private." Public data may be altered by any other object. Most data, however, is private and accessible only to methods owned by the object. Typically, the methods operate on the private data contained in the object.
A collection of similar objects make up an interface (or "class" in C++ parlance). An interface specifies the methods and types of data contained in all objects of the interface.
Objects are then created ("instantiated") based upon that interface. Each object contains data specific to that object. Each specific object is identified within a distributed object system by a unique identifier called an object reference.
In a distributed object system, a client sends a request (or "object call") containing an indication of the operation for the server to perform, the object reference, and a mechanism to return "exception information" (unexpected occurrences) about the success or failure of a request. The server receives the request and, if possible, carries out the request and returns the 25 appropriate exception information. An object request broker ("ORB") provides a communication hub for all objects in the system passing the request to the server and returning the reply to the client.
On the client side, the ORB handles requests for the invocation of a method and the related selection of servers and methods. When an application sends a request to the ORB for a method to be performed on an object, the ORB validates the arguments contained in the request against the interface and dispatches the request to the server, starting it if necessary. On the server side, the ORB receives such requests, unmarshals the arguments, sets up the context state as needed, invokes the method dispatcher, marshals the output arguments, and returns the results to the client, thereby completing the object invocation.
Both client and server must have information about the available objects and methods that can be performed. Through the hiding of private data ("encapsulation" in object-oriented parlance), the client does not need to know how the request will be carried out by the server. Nevertheless, both client and server must have access to common interface definitions to enable communication therebetween. Currently, the standard language for distributed object computing is the Object Management Group's ("OMG") Interface Definition Language ("IDL").
IDL interfaces define a set of operations that a client can invoke on an object. An interface can declare one or more exceptions, which indicate that an IDL operation did not perform successfully. Operations may receive parameters and return a return value. Each parameter to an operation may have a "direction" that indicates whether the value is passed from client to server ("in"), from server to client ("out"), or in both directions ("inout"). The parameter also has a data type that constrains its possible values. Operations may also optionally have a "one-way" attribute, which specifies which invocation semantics the communication service must provide for invocations of a particular operation. When a client invokes an operation with the one-way attribute, the invocation semantics are "best-effort", implying that the operation will be implemented by the server at most once. If an attempt to implement the operation fails, the server does not attempt to implement the operation again. An operation with the one-way attribute must specify a void return type and must not contain any output parameters.
Data types are used to describe the accepted values of IDL operation parameters, exceptions, and return values. IDL supports two categories of data types: basic and compound. Basic types include short integers, long integers, long long integers, unsigned long integers, unsigned short integers, floating points, double, character, boolean, and octet. Compound types include enum, string, struct, array, union, sequence, and "any" types. The struct type is similar to a C structure; it lets interface designers create a complex data type using one or more type definitions. The sequence type lets interface designers pass a variable-size array of objects. The "any" type can represent any possible data type--basic or compound.
IDL is designed to be used in distributed object systems implementing OMG's Common; Object Request Broker Architecture ("CORBA"). In a typical CORBA system, interface definitions are written in an IDL-defined source file (also known as a "translation unit"). The source file is compiled by an IDL compiler that maps the source file to a specific programming language. The IDL compiler generates programming-language-specific files, including client stub files, header files, and server skeleton files. Client stub files are then compiled and linked into client applications and are used to make requests. Header files are linked into client and server applications and are used to define data types. Server skeleton files are linked into server applications and are used to map client operations on objects (requests) to methods in a server implementation.
An IDL compiler typically acts as a compiler and a code generator. The compiler produces the stub, header, and skeleton files directly. The original source code is not preserved in a file or database once compiled. Access to the original source code is important, however, for generating code to help perform object calls using different models, such as RPC style stubs and message packing functions. In addition, the source code may need to be accessed to extract, edit, and recompile if changes to an IDL translation unit must be made.
CORBA does provide an interface repository to allow dynamic access to IDL interface definitions. The primary function of the interface repository, however, is to provide information for dynamically invoked requests. Thus, the interface repository contains the same information that is otherwise stored in client stubs. The original IDL source code is not directly accessible. Moreover, the interface repository contains all available interfaces in a large database, rather than specific interfaces related to a particular IDL translation unit. Access to a particular translation unit would be more flexible.
Accordingly, a need exists for an intermediate format between compilation and actual code generation that permits access to the original IDL source code.
Further, a need exists for an intermediate format that can be readily stored in a file and accessed dynamically.
Further, a need exists for an intermediate format that can represent a single IDL translation unit.